Embodiments of the present disclosure generally relate to wireless communications, and more particularly, to uplink scheduling requests and related methods and user equipment and network nodes.
A Scheduling Request (SR) is used to request uplink shared channel (UL-SCH) resources for a dedicated data transmission from a user equipment node (also referred to as a wireless terminal, a user equipment, UE, etc.) to a network node (also referred to as a base station, an eNB, an eNodeB, etc.). A Scheduling Request SR may be sent as a Dedicated SR (D-SR) on the Physical Uplink Control Channel (PUCCH), or a Scheduling Request SR may be sent as Random Access Scheduling Request (RA-SR) by triggering a Random Access (RA) request for new UL scheduling resources on a Physical Random Access Channel (PRACH). FIG. 1 is a block diagram illustrating procedures and channels involved in such D-SR and RA-SR communications between a base station and a user equipment UE in an LTE (Long Term Evolution) uplink.
A D-SR may include one single bit of information that is transmitted from the UE to the base station, carried by the presence or absence of a preselected PUCCH format on a preconfigured PUCCH time/frequency resource. FIG. 1 illustrates the Evolved Universal Terrestrial Radio Access (E-UTRA) radio interface protocol architecture used above and around the physical layer. The physical layer is configured by the Radio Resource Control (RRC) Layer of Layer 3 and interfaces the Medium Access Control (MAC) sub-layer of Layer 2. Resources for D-SR are assigned and revoked through explicit Radio Resource Control (RRC) signaling, and resources for D-SR may be implicitly released when the UE can no longer remain synchronized in the uplink.
FIG. 2 illustrates elements of a SchedulingRequestConfig information element according to 3GPP 36.331 (E-UTRA RRC) used to define resources for D-SR. In particular, RRC uses a SchedulingRequestConfig information element including a first 11 bit index sr-PUCCH-ResourceIndex (also referred to as Index-1) to define a code frequency domain of the PUCCH assigned for the D-SR resource(s), and a second 8 bit index sr-ConfigIndex (also referred to as Index-2) to define a time domain of the PUCCH assigned for the D-SR resource(s). The SchedulingRequestConfig information element thus defines a maximum set of transmission opportunities of a D-SR on PUCCH. FIG. 3 is a block diagram illustrating processing of a SchedulingRequestConfig information element using RRC and PHY.
Index-1 (sr-PUCCH-ResourceIndex) points to positions in code frequency space. Index-2 (sr-ConfigIndex) is coupled to a periodicity P and a subframe offset O as defined in the table of FIG. 4. Typical D-SR periodicities may range from 10-20 ms (corresponding to indices 5-14 and 15-34 of FIG. 4), with shorter 1, 2 and 5 ms periodicities (corresponding to indices 0-4, 155-156, and 157 of FIG. 4) being meant for data with critical latency requirements, and with longer 40 and 80 ms periodicities (corresponding to indices 35-74 and 75-154 of FIG. 4) being used for more relaxed data requirements.
In FIG. 4, the first column (SR configuration index) provides the index values used for sr-ConfigIndex (Index-2) of FIG. 2, the second column (SR periodicity P) provides the periodicity in milliseconds (ms) associated with the respective index value, and the third column (SR subframe offset O) provides the SR subframe offset associated with the respective index value (calculated as the index value minus the indicated integer). The base station may thus transmit a SchedulingRequestConfig message including one of the index values of FIG. 4 as an sr-ConfigIndex (Index-2) to the UE to identify D-SR resources available to the UE to make scheduling requests. Relatively short periodicity (high frequency) D-SR assignments (e.g., corresponding to indices 0-4 and 155-157) may provide reduced latency for a UE with data having relatively strict latency requirements at a cost of relatively high consumption of system resources. Intermediate periodicity (intermediate frequency) D-SR assignments (e.g., corresponding to indices 5-34) may provide intermediate latency for a UE with data having intermediate latency requirements. Relatively long periodicity (low frequency) D-SR assignments (e.g., corresponding to indices 35-154) may provide relatively low consumption of system resources at a cost of relatively high data latency.
Peak loads of LTE networks are steadily increasing, pushing capacity requirements measured in numbers of RRC Connected UEs per cell. Available capacity may depend on a number of resources, and more particularly, on semi-static PUCCH resources. If the system exhausts its PUCCH resources, the UEs may be required to use random access to request resources, and use of such random access requests may be a more tedious and time consuming procedure, compared to sending an SR over PUCCH. Increased use of random access requests may result in increased load on the resources for random access and such increased load may limit system capacity.
In LTE, uplink transmissions may only be allowed when the UE is synchronized in the uplink. If a UE is not synchronized in the uplink, the UE may be required to re-synchronize (using a random access procedure) before it is allowed to transmit anything other than a preamble (e.g., used for a random access request). Thus, each LTE UE that is RRC Connected may be either UL synchronized or not UL synchronized. As shown in FIG. 5, a UE can be in either an RRC Idle state or an RRC Connected state, and if a UE is in an RRC Connected state, the UE may be either not UL synchronized or UL synchronized.
By using PUCCH resources, UL and DL throughput may be improved and latency may be reduced for a UE in a UL Synchronized state, but as noted above, PUCCH resources may be relatively scarce, and thus, availability of such resources may be limited. Stated in other words, PUCCH resources may not be available for all UEs that are in an RRC Connected state, so that some RRC connected UEs may be not UL synchronized.
A UL synchronized UE may lose UL synchronization when the system/RAN stops maintaining its UL time alignment. If that happens, the system/RAN may release any semi-static PUCCH resources (SR, CQI) that it may have for the UE so that the UE transitions from UL synchronized to Not UL synchronized.
For a heavily loaded system/RAN, it may be beneficial to have only a subset of the RRC Connected UEs in the UL synchronized state in a cell, so that an increased number of UEs can be RRC Connected without increasing semi-static PUCCH resources during peak load scenarios.
Maintaining a UE in a not UL synchronized state, however, may increase latency for data transactions for UEs in the not UL synchronized state. When a data transaction is needed, the not UL synchronized UE may first be required to regain UL resynchronization. The UE initiates re-synchronization using a random access procedure, before it can send any UL data. Moreover, if the network needs to send data or control information to the UE, the network may need to force the UE to synchronize in order to receive the required response.
In addition, a UE in a not UL synchronized state may lack immediate resources for uplink data transmission. A UE which has regained UL synchronization may not yet have been assigned PUCCH resources, and instead, the UE may be expected to send a buffer status report (using a minimal UL grant received at content resolution) before such PUCCH resources are assigned.
Because a not UL synchronized UE may need to use a random access procedure to regain UL synchronization and to then send a buffer status report before PUCCH resources are assigned, user plane latency for the UE may be increased, and reductions in such delay/latency may be desired.
Triggers for current methods to configure PUCCH resources using RRC may be relatively slow, delaying initiation of UL synchronization and configuring of PUCCH resources. As a result, a UE may be without D-SR resources for a significant number of Transmission Time Intervals (TTIs) after UL re-synchronization, and the UE may be required to continue using RA-SRs (Random Access Scheduling Requests) to request UL data transmission resources. Accordingly, user plane latency and load on random access resources may be further increased.
A delay until a UE can use D-SR may depend on network load and implementation, and also on UE implementation, and the delay may typically vary between 13 and 50 ms. This is a relatively long time that leaves open the possibility that the UE will again trigger the same contention based procedure for random access to request resources. The RA-SR using contention based random access (CBRA) may require more time than the D-SR. Depending again on the load and other contending/competing UEs, scheduling using CBRA may take twice as long as scheduling using a D-SR with dedicated PUCCH resources. In addition, RA-SR may require more overhead signaling.
Not UL synchronized UEs may thus be subject to increased latency due to the time needed for re-synchronization and/or due to a lack of D-SR resources immediately available after re-synchronization.